Извлекая полезный опыт IT-компаний

Я работал уже больше 12 лет в разных IT-компаниях и захотел в порыве ностальгии выписать разницу между ними, лучшие стороны, что-бы вы тоже могли научиться у них. Поехали..

Внутренняя прозрачность улучшает культуру и здоровье компании

Практика периодической финансовой отчётности начальства перед своими работниками сильно успокаивает. Это происходит в форме докладов «мы выиграли проект на X тысяч евро», «мы пробуем такой-то гос-тендер» или «вот как наша цель по прибыли соответсвует действительности», «у нас наличных на X лет выплаты зарплат», «мы прибыльны». Врядли кто-то доходит до радикальной прозрачности где все знают какая у кого зарплата.

В более общем виде, внутренняя прозрачность компании проявляется в том что каждый работник знает то что его не касается напрямую - какие проекты выпустились какой-то коммандой (demo meeting), какие ошибки и инциденты возникают в продуктах (доступный всем error log), что хотят клиенты (feedback), какие бизнес-метрики у проектов (analytics). 

В обычных компаниях доступ к гугл-аналитике есть только у избранных, вы как работник можете только догадываться о финансовом положении компании, с реальными клиентами разработчики не общаются, а NDA ограничивает внутреннее общение между командами.

При этом каждый продукт (В Apple) имеет свой NDA, поэтому ты часто не знаешь, над чем работает твой сосед, и вы ничего не можете обсудить

Ирина Березань, разработчик

Управление проектом это воронка

Управление проектом это сложный процесс и в хороших компаниях он настроен оптимально. Это проявляется в еженедельных совещаниях по разгребанию планов, которые разбиваются на иерархию и превращаются в документацию и оценку по времени. Чем детальней разбивается задача, тем больше людей должны её обсуждать и тем точней будет оценка. Процесс постепенный и цикличный (поэтому воронка).

Если коротко, то:

1. PM продумывает и создаёт Features. Фича может затрагивать разных действующих лиц и разные сценарии использования.
2. PM + grooming team создают User Stories. Это сценарии использования конкретных лиц
3. TL создаёт Tasks. Это технические задачи по измнению конкретного сервиса. Связываются друг с другом и со сценарием

Непонятные задачи нуждаются в изучении которое ограничено по времени. Пожелания по улучшениям и рефакторингу выписываются в отдельный список (parking lot), который можно сделать отдельным спринтом.

В обычных компаниях, нет постоянства в митингах, ритм рванный - то аврал, то кодинг с запоем. Требования остаются слишком абстрактными и разработчик как творец, сам решает как он их понимает, что-бы потом переделать. Поскольку требования не записываются, теряются причины решений. 

Традиции и игры сближают коллектив

Офисная работа не пыльная, но сильно может давить на психику. Что-бы отвлечься некоторые компании стимулируют отдых за настольным футболом, mortal combat или fifa в PS4, а в особых случаях и коллективным турниром в LoL, Dota или Red Alert 2. В некоторых компаниях, принято что работники угощают коллектив собственными кулинарными произведениями на праздники. В обычных компаниях быту не уделяют столько внимания

Команда многофункциональна и специализирована

В обычных компаниях каждый член комманды (макс 10 чел) имеет чёткую специализацию - дизайнер, frontend, backend и тд. Это даёт хорошую эффективность при равномерной нагрузке. Но такая команда ограничена пропускной способностью самого слабого звена (скажем мануальным тестером или дизайнером).

В хороших компаниях каждый член команды умеет рисовать, верстать, проектировать API и БД, деплоить и тестировать (т.е. он кроссфункционален). Он не так хорош как тот специалист с 10-летним стажем, но при этом играет конкретную роль (я например - в основном backend и архитектура). Болезни или отпуска мало влияют на эффективность комманды, т.к. она масштабируется линейно независимо от типа задачи.

Асинхронные процессы

Асинхронность значит что теперь все  всё записывают  и не  прерывают работу  друг друга. Всё работает как в nodejs на основе событий или callback-ов. 

• Общение проходит в основном через групповой чат (по которому можно искать)
• Каждый митинг имеет письменный результат работы (meeting notes), последствия для участников (action points) и  live видео-трансляцию с видео-записью
• Результат работы проходит фазу review. Тексты для user-stories и документации можно inline-комментировать в Confluence. Вёрстку дизайна в Zeplin/Sketch тоже можно ревьюить.
• Самое главное, все изменения кода и конфигурации инфраструктуры в проекте проходят через  коммандный pull-request review . 

Всё это делается для тех работников, кто не может  присутствовать в этом же пространстве-времени , для  долговременной памяти компании ,  масштабируемости организации  и наконец для глобального поиска.

В обычных компаниях 

• митинги никто не записывает

• все друг друга прерывают - разработчики прерывает PM/дизайнера что-бы понять что именно надо, QA что-бы объяснить как что тестировать, Opsов - как деплоить готовую работу из-за особенностей конфигурации. И наоборот, PM/ops может прерывать разработчиков из-за багов или из-за горящих сроков

• ревью кода не проходит через всю комманду - достаточно подтверждения кода от TL и функциональности от QA

Быстрый автоматический деплоймент

В хороших компаниях деплоймент происходит как только микро-задача готова - каждый день или каждую неделю, а не пачкой раз в пол года. Это решается дублированием и скрытием новой функциональности (т.н. feature-toggling) которая ко всему прочему позволяет накатывать изменения части клиентов и проводить A/B тестирование. 

Во-вторых, деплоймент автоматизирован настолько, что при подтверждении pull-request'а, изменения сами попадают на production, а не ждут ручного деплоймента. Это требует не только хорошего конвейера непрерывной сборки проекта с автоматическим тестированием, но и хорошего мониторинга ошибок и возможности отката изменения (контейнеризация)

Быстро меняющиеся проекты расширяют кругозор

Это возможно пожалуй только в маленькой студии. Если вам не нравится пилить CMSку, то через 3 месяца вы уже познакомитесь с CRMкой, ещё через 4 — с ITIL, SMS-gateway или индексацией. Быстро меняющиеся проекты позволяют и быстро менять технологии, пробовать новые фреймворки. Минимум бюрократии, максимум эффективности.

Внимание к рабочему месту влияет на качество кода

В хороших компаниях серьёзно относятся к рабочему месту. Разработчикам дают лаптопы (макбуки), хорошие монитор(ы), хорошие стулья и регулирующиеся по высоте столы. Эти инвестиции поднимают работнику самоуважение, не дающей писать говнокод по «теории разбитых окон». Лаптопы лучше стационарных т.к. их можно брать на совещания и работать из дома. Пространство офиса организуется по принципу группировки в команды так что-бы минимизировать уровень фонового шума и максимизировать общение этой группы. В обычных компаниях open space, разношёрстная мебель и железо, которое ещё надо выбивать

Если вы как разработчик чувствуете что вам этого не хватает, то у нас в Pipedrive все эти пункты отличные. И мы нанимаем кадры